explore(desktop): discovery-first onboarding landing (Discord-style) - #5976

Two blockers remain in the discovery-first join path:

• communityOnboarding.start() deliberately returns false when a different onboarding transaction is already pending. quickJoinCommunity ignores that result and still calls complete(identity.pubkey). An acknowledged deep-link transaction therefore lets the user click a featured card, completes machine onboarding, and then connects the other pending community instead of the one shown.
• Three cards are marked openJoin: true even though their relay hosts do not resolve (agents.buzz.builderlab.xyz, nostr.buzz.builderlab.xyz, and nomads.buzz.builderlab.xyz). DiscoveryLanding never consults openJoin, so all three dead endpoints are advertised as working one-click joins.

I fixed both in Complear:review/pr-5976-fix at 01bc5be66f5b4ed54380c7655aa7794bc8f779b7: rejected transaction starts now leave machine onboarding incomplete and show an actionable error; unavailable entries render disabled “Coming soon” buttons; and the E2E spec covers both the disabled catalog entries and the pending-transaction collision.

Verification:

• fresh pnpm build:e2e — passed
• focused discovery Playwright suite — 2 passed
• screenshot SHA-256 check — all 3 states distinct
• focused Biome — clean
• pnpm exec tsc --noEmit — passed
• pnpm test — 4,954 passed

:bot: Jude’s code review agent — requesting changes at exact head 3ddaa0d59d6192cf49877bfeb7d5d94702d90101 (base 78cbffeb64c01220e705adf0aa9690fdbd0d7a37).

1. High — three of four first-run choices are fictional, actionable communities

desktop/src/features/onboarding/featuredCommunities.ts:25-60 marks all four entries openJoin: true and supplies exact member counts, while desktop/src/features/onboarding/ui/DiscoveryLanding.tsx:51-92 renders every entry with an enabled Join action and never consults openJoin. At review time, only buzz.block.builderlab.xyz resolved; agents.buzz.builderlab.xyz, nostr.buzz.builderlab.xyz, and nomads.buzz.builderlab.xyz had no A record and curl failed with Could not resolve host.

That makes three primary first-run actions guaranteed dead ends after Buzz has silently created an identity and completed machine onboarding. The invented membership counts also present nonexistent groups as established social proof. Do not ship placeholder directory entries as actionable production data. Limit the compiled catalog to verified open relays, or visibly disable/segregate fixtures; source availability and counts from a trusted directory before presenting them as live facts.

Reproduction:

for h in buzz.block.builderlab.xyz agents.buzz.builderlab.xyz nostr.buzz.builderlab.xyz nomads.buzz.builderlab.xyz; do
  dig +short "$h" A
  curl -sS --connect-timeout 5 --max-time 10 -o /dev/null \
    -w '%{http_code} %{errormsg}\n' "https://$h/"
done

2. High — a rejected join transaction still completes machine onboarding

desktop/src/features/onboarding/ui/MachineOnboardingFlow.tsx:168-180 ignores the boolean returned by communityOnboarding.start(...) and always calls complete(identity.pubkey). But desktop/src/features/onboarding/communityOnboarding.tsx:340-350 intentionally returns false when an existing transaction targets a different relay. With an acknowledged pending deep-link transaction, choosing Buzz HQ therefore completes machine onboarding while preserving and connecting the older community; the card the user selected is silently discarded.

Treat false as a failed start: do not complete machine onboarding, and surface an actionable choice to resume or replace the existing transaction. Add a permanent collision test proving the selected relay wins or the user remains in onboarding with clear feedback.

3. High — the changed first-render contract leaves exact-head Desktop CI red

The new landing replaces recovery controls on first render, but the existing onboarding suite still drives those controls directly. Six tests time out at desktop/tests/e2e/onboarding.spec.ts:708,799,822,846,870,924; exact-head checks fail in Desktop E2E Integration (1/2), smoke shards 2/3, and both aggregate Desktop jobs. This is directly coupled to the PR's first-screen change, not an unclassified infrastructure failure. Update the affected workflows to enter recovery through the new landing and keep their original recovery assertions intact.

Evidence:

gh pr checks 5976 --repo block/buzz
gh run view 31900028469 --repo block/buzz --log-failed

4. Moderate — every community action has the same accessible name

desktop/src/features/onboarding/ui/DiscoveryLanding.tsx:80-89 exposes four buttons named only Join; the community name is not programmatically associated with each button. A screen-reader button list cannot distinguish the choices. This misses the repository's WCAG 2.1 AA floor (VISION.md:196-207). Give each action a community-specific accessible name, for example Join Buzz HQ, and assert those names by role.

Validation and required regression shape

At this exact head, independent runs passed pnpm typecheck, pnpm check, pnpm build:e2e, all 4,954 Desktop unit tests in one run, and the authored discovery Playwright spec. One separate full-unit run had a single long-running terminalBannerWave.test.mjs worker failure after 4,934 passes; that target then passed 20/20 alone, so I am not attributing it to this PR without a main comparison.

The new desktop/tests/e2e/discovery-landing-shot.spec.ts proves visual rendering, the advanced/back route, and one mocked Buzz HQ happy path. It does not discriminate the rejected-transaction collision, dead/unavailable entries, community-specific accessible names, real relay selection, or connection failure recovery. Please add those risk-shaped cases and provide exact-artifact evidence for at least one real endpoint join plus one truthful failure/recovery path.